Exchange server 2010 : Troubleshooting Tools (part 2)

3. Identifying and Resolving Exchange Server Issues

The event logs are one of the most valuable resources available to administrators for identifying issues. Windows 2008 introduces some changes to the familiar tool. The legacy Windows logs category still exists, and there is a new category for Applications and Services. The Windows logs category adds two new logs: the Setup log and the ForwardedEvents log. These are intended to contain events that apply across the entire system.

The Applications and Services logs store events from a single application or sub-component. This new channel is code-named the application's crimson channel and is part of the new event logging API. The Application and Services logs have four sub-types, shown in Table 5.

Exchange 2010 utilizes the Application and Service logs channels for HighAvailability and MailboxDatabaseFailureItems. These logs are located on a mailbox server by performing the following steps:

If you follow these steps your Event Viewer MMC will resemble Figure 7.

The HighAvailability channel contains information from the Microsoft Exchange Replication service. The Active Manager logs events related to mounting/dismounting, reseeding, and other database operations. The Volume Shadow Copy Service (VSS), Cluster service, and TCP listener will also log events here.

The MailboxDatabaseFailureItems channel logs events associated with any failures that affect a replication mailbox database.

3.1. DAGs and Mailbox Copies

Exchange 2010 ships with a number of scripts that help collect and report on database metrics. These in-box tools are an easy way to show whether the Exchange system is meeting the defined service levels. Additionally, these reports can help an administrator tune the environment if not meeting the SLAs. The scripts are located in the [Exchange install path]\scripts directory. They must be run from an EMS.

The first script is named CollectOverMetrics.ps1. It will collect and report on information related to fail and switchover statistics. Microsoft refers to these database moves as *overs; a generic way to refer to any time the database moves between hosts. A number of parameters are available for customizing the script, but most useful is the ability for the script to output an HTML report. The following command will collect all of the metrics and generate a report:

./CollectOverMetrics.ps1 -GenerateHTMLReport

The script was rewritten for Service Pack 1, and shows considerably more output—more than 40 metrics. Table 6 lists some of the information that is returned in the HTML report.

The second script is CollectReplicationMetrics.ps1. This is useful for troubleshooting because it collects metrics in real time. The output statistics are shown in Table 7.

3.2. Public Folder Troubleshooting

When it came to public folder management, Exchange 2010 seemed to take a step backward with public folder management with the EMC. Fortunately, Service Pack 1 brings back the ability to manage public folder settings. Because many companies still have public folders deployed, this will make administration easier for administrators not proficient with PowerShell and the *-PublicFolderClientPermission cmdlets.

Another addition in Service Pack 1 is a new Repair-PublicFolderDatabase cmdlet. This cmdlet can be used to detect and fix the following public folder corruptions:

• Public folder replication state

• Public folder view verification

• Public folder physical corruption

3.3. Client Access Server Troubleshooting

Of course, not everything will always run as smoothly as planned. This section describes some techniques to handle common issues or check on your Client Access Server's health.

3.3.1. Client Access Server Test Cmdlets

You can use a number of PowerShell cmdlets to test Client Access Server health. Table 8 lists the relevant PowerShell cmdlets with a description. Many of the cmdlets can target a specific user as a parameter. The New-TestCASConnectivityUser.ps1 script located in the scripts directory will create a test user that you can use with these cmdlets.

$temp=Test-SystemHealth -OutData

Set-Content -Value $temp.FileData -Path
c:\temp\SystemHealthOutData.xml -Encoding Byte

3.3.2. Autodiscover

AutoDiscover can be complex to configure correctly when you have a variety of clients coming in from both inside and outside the corporate network. Fortunately, Microsoft has given you a number of tools to help troubleshoot AutoDiscover. The first thing to check is a tool built into Microsoft Outlook. After launching Outlook, press and hold the Ctrl key and right-click the Outlook icon in the system tray. A hidden menu item will appear named Test Email AutoConfiguration. Simply type in an e-mail address and password and run the test. This will return all of the Autodiscover information that it discovers. From the protocol property, you can see the queries to find an SCP object or the queries via DNS as well as the configuration returned for internal (RPC or EXCH) and external (HTTPS or EXPR) connectivity. If it cannot locate Autodiscover information, check the Log tab. This tab shows all of the different methods Autodiscover uses to establish a connection. This can help narrow down which methods are failing. Make sure from the client you can resolve the DNS name correctly using a common tool, such as nslookup.

Another method for troubleshooting Autodiscover is using Windows PowerShell from an Exchange server. The Test-OutlookWebServices cmdlet tests Autodiscover and also the service settings Autodiscover returns. Simply run the Test-OutlookWebServices cmdlet with the –Identity parameter set to a user's e-mail address; for example, Test-OutlookWebServices –Identity [email protected].

3.3.3. Remote Connectivity Analyzer

The newest of the analyzers, the Remote Connectivity Analyzer, is not included in the EMC Toolbox. This Web-based tool is located at https://www.testexchangeconnectivity.com. Figure 8 shows the home page and the various tests an administrator can perform with this Web site.

Table 9 explains the various tests and how they can be used for troubleshooting.

The Remote Connectivity Analyzer provides step-by-step detail to pinpoint where exactly in the test any failures occurred. Of course these tests are all run from the Internet, so they will not help troubleshoot issues from inside the corporate network perspective.

3.3.4. Certificates

Troubleshooting certificates can be challenging. Even though the certificate management MMC may import a certificate and not report any issues, Exchange may fail to import the certificate. This is because the MMC snap-in only requires basic hierarchy validation and does not perform additional checks. Exchange requires a much more vigorous validation checking, including a certificate revocation check. You can check the certificate status with the get-ExchangeCertificate cmdlet. If the import fails or there is an issue, the status field will report invalid. Another symptom is the services using SSL or TLS will fail to start, resulting in the following error:

Note:

Description The IMAP4 service failed to connect using SSL or TLS encryption. A valid certificate is not configured to respond to SSL/TLS connections. Check the configured hostname as well as which certificates are installed in the Personal Certificates store of the computer.

One way to troubleshoot these types of errors is to export the certificate and run the certutil utility to verify the certificate. The syntax is:

Certutil -verify filename

Examine the output and see whether the error relates to the ability to check the certificate's revocation status. The Exchange server might be unable to connect to the revocation point because of a server proxy configuration error or Internet connection problem.

3.3.5. IIS Virtual Directory Troubleshooting

Occasionally an administrator may need to re-create the IIS virtual directories, such as OWA. Maybe the configuration was changed inappropriately, or the Web site was damaged. In Exchange 2010 RTM, this was only achievable with PowerShell cmdlets such as New-OWAVirtualDirectory. In Service Pack 1, this ability was added to the EMC. When an administrator selects a Client Access Server in the EMC, there is a new action called Reset Virtual Directory. This action will guide the administrator through a process that will delete and re-create a virtual directory back to the initial default settings.